Brief Full Advanced Search Search Tips
|  |  | To access the contents, click the chapter and section titles. Visual Basic 6 Programming Blue Book: The Most Complete, Hands-On Resource for Writing Programs with Microsoft Visual Basic 6! (Publisher: The Coriolis Group) Author(s): Peter G. Aitken ISBN: 1576102815 Publication Date: 08/01/98 Search this book:
Previous | Table of Contents | Next
### Using The Comm Control While serial communication is simple in principle, in practice you’ll quickly understand what people mean when they say, “The devil is in the details.” Serial communication is filled with details, including the various handshake lines that may or may not be used in a specific situation, the importance of setting the serial parameters properly, and so on. Fortunately, Microsoft has extended the concept of software components to this problem, providing us with the Communication, or Comm, control (sometimes called the MSComm control), which greatly simplifies the job of supporting serial communication in your Visual Basic programs. The Comm control is not visible during program execution, because its sole job is to act as an intermediary between your program and a serial port. You can have two or more Comm controls in a program—each linked to a different serial port. Data to be transmitted is placed in one of the control’s properties; data received by the serial port is retrieved from another of the control’s properties. Additional properties are used to set and read serial port parameters. Before we look at these properties in detail, we need to understand the two basic methods of using the Comm control. #### Polling Vs. Event-Driven Communication One of the more difficult aspects of serial port programming is dealing with incoming data. To be more precise, the problem lies in knowing when data has been received by the port and is available to be read by the program. The Comm control offers two approaches to this problem: • Polling—The traditional method by which Basic programs handled serial communication before the advent of the Comm control. It is still supported by the Comm control and is perfectly suitable for some applications. This method requires the program code to check the status of the serial port on a regular basis to see if data has been received, if an error has occurred, or if a change has occurred in the status of the handshaking lines. • Event-driven communication—A more powerful technique in which the Comm control generates an event whenever data is received. Your program does not have to sit idly waiting for data. It can busy itself with other tasks and still respond immediately whenever the serial port has data to be read. The same event is also triggered if a communication error occurs, or if one of the handshaking lines changes status. Polling may be perfectly suitable for relatively simple applications, such as a phone dialer, where the program only has to keep an eye on the serial port. For more demanding applications, however, you will find that the event-driven approach is superior. #### Comm Control Properties The Comm control has a long list of properties, many of which are unique to this control. Some of these properties are related to the various handshaking protocols and signal lines that serial ports support. We won’t discuss these advanced properties here, because they are rarely involved in basic serial communication. Rather, we will concentrate on the more fundamental properties always associated with the Comm control. Setting Serial Port Parameters You set serial port parameters by means of the CommPort and Settings properties. CommPort specifies the serial port to which the control is linked. It can be set to any value between 1 (the default) and 99, but an error will occur if you specify a port that does not actually exist on the system in use. You must set the CommPort property before the port can be opened. Communication parameters, such as baud rate and parity, are designated by using the Settings property. You place a string with the following format in the Settings property:
    BBBB,P,D,S
In this Settings string, BBBB is the baud rate, P is the parity, D is the number of data bits, and S is the number of stop bits. If you do not explicitly change a Comm control’s parameters, the default settings are 9,600 baud, no parity, 8-bit data word, and 1 stop bit. The valid baud rates are 110, 300, 600, 1,200, 2,400, 9,600, 14,400, 19,200, 38,400, 56,000, 128,000, and 256,000. Table 15.1 shows the valid parity values. The valid data-bit values are 4, 5, 6, 7, and 8, which is the default. Valid stop-bit values are 1 (the default), 1.5, and 2. For example, the following code would set the Comm control named Comm1 to link with serial port 1, using 9,600 baud, no parity, an 8-bit data word, and 1 stop bit:
    Comm1.CommPort = 1
    Comm1.Settings = “9600,N,8,1”
Sending And Receiving Data Before reviewing the details of how the Comm control sends and receives data, you need to understand the concept of a buffer. A buffer is a temporary storage location where data is held before processing. The Comm control has two buffers: input and output. Proper use of these buffers simplifies serial port programming and results in more reliable communications.
Table 15.1 Parity settings.
Setting | Description
--- | ---
E | Even
M | Mark
N | None (default)
O | Odd
S | Space
When your program sends data to the Comm control for transmission, the data is placed in the output buffer. The Comm control reads data from the buffer and transmits it. Likewise, when the Comm control receives data, the data is placed in the input buffer, where your program can read it. Reading the Input property removes the data from the buffer, so there is no danger of reading the same data twice. These buffers allow your program to operate without being perfectly synchronized with the serial port. If your program sends data to the Comm control faster than the serial port can transmit it, no problem. The extra data will remain in the output buffer until it can be transmitted. Similarly, if your program is reading data from the Comm control more slowly than the serial port is receiving it, the input buffer will hold the data until the program catches up. Without these buffers, your program would have to use the various handshaking signals to ensure that its activities are synchronized with the serial port—a difficult programming task, to be sure. The output buffer’s default size is 512 bytes. To set a different buffer size or determine the current size, use the OutBufferSize property. The default setting is usually sufficient, but you will need to increase it if an overflow error occurs (error handling is covered later in the chapter). Setting the output buffer size too large will not improve performance; it will only reduce the amount of memory available to the application.
Previous | Table of Contents | Next

| Products | Contact Us | About Us | Privacy | Ad Info | Home Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc. All rights reserved. Reproduction whole or in part in any form or medium without express written permission of EarthWeb is prohibited. Read EarthWeb's privacy statement.